System and methods for generating a regulatory alert index using modularized and taxonomy-based classification of regulatory obligations

ABSTRACT

A system is provided for generating a regulatory alert index using modularized data and taxonomy-based classifications of regulatory obligations. The system comprises a plurality of databases storing regulatory compliance data and a plurality of processors that process the regulatory compliance data to generate business requirements for complying with regulatory obligations. The plurality of processors are further configured to identify new regulatory compliance data published by regulating entities and update the corresponding stored regulatory compliance data when new information is identified. A taxonomy engine is also provided that determines a regulatory alert index score for each of the generated business requirements based on how often the plurality of processors identify new regulatory compliance data related to the generated business requirement.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the priority benefit ofU.S. Provisional Patent Application No. 62/167,146, filed May 27, 2015,which is incorporated herein by reference, except that in the event ofany inconsistent disclosure or definition from the presentspecification, the disclosure or definition herein shall be deemed toprevail.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present disclosure relates generally to compliance and legalservices field, and more particularly, to systems and methods forintelligent regulatory classification through the creation of anattribute-based classification system of all qualitative data andutilization of an intelligent taxonomy structure to, among otherapplications, automatically generate regulatory compliance data andrelated information.

2. Description of the Background of the Invention

There has been an explosion of regulatory law promulgated in the UnitedStates. The length, quantity, and complexity of all of these laws areincreasing rapidly. Currently, there are no solutions equipped tointelligently classify these obligations in a usable manner. Currentprocesses (which are distinct from the processes contemplated by thepresent disclosure) are not capable of analyzing regulatory complianceissues in a similar manner, are inefficient, prone to error, and unableto efficiently respond to the ever-changing regulatory landscape.Further, current system-based services utilized in other regulatorycompliance industry suffer from many further shortcomings, including notproviding for dynamic generation of relevant data, alteration of thetext itself, and cannot meaningfully support regulatory compliance in acontinuously ongoing fashion. This problem costs companies millions ofdollars in research and transaction costs, and spiraling inefficiencies.

SUMMARY OF INVENTION

The present disclosure contemplates, in one or more embodiments, asystem that will quantitatively classify all regulatory laws via anassigned taxonomical structure. In one aspect, the system will queryusers to answer a series of intelligently curated questions based on aseries of attributes. The curated questions are particularly created bythe system designers to elicit user-specific information that is used bythe back-end architecture to intelligently classify assign theregulations relevant to a specific company, and to automaticallygenerate regulatory compliance information tailored to that company andits business operations.

In one embodiment, the present disclosure contemplates an intelligentsorting and curation of regulatory law, and legal-based content. Itfurther contemplates the intelligent sorting and parsing of anyqualitative structure of a set of text by parsing such words into aninstructional string that can be allocated based on taxonomicalstructures.

In one or more additional embodiments, the present disclosurecontemplates a quantitative classification via taxonomy of all laws andregulations in every jurisdiction. This can be done on a variety ofregulatory levels, such as for cities/municipality laws and regulations,county-wide laws and regulations, state-wide laws and regulations,federal laws and regulations, and the laws and regulations of othercountries. In some embodiments, the system automatically processes theregulations at each levels as a series of strings of text (word-based asa rule, law, or general text), which are distilled down to a basicversion of text. That “lowest-common-denominator” string will then havea taxonomy applied to it. This taxonomy will be applied to all selectedtext strings, and the text strings will subsequently be sorted,classified, and utilized by the system to automatically generateregulatory compliance information in automated fashion.

In other embodiments, a system is provided having a graphical userinterface that allows a user to enter responses to questions that areintelligently curated based on a series of attributes determined aboutthe user. In particular, the user's answers to the curated questionselicit user-specific information and the systems back-end architecture,consisting of one or more distributed network servers, processors,and/or databases, utilizes the user's answers and the aforementionedtext strings that are sorted and classified by the taxonomy in order tointelligently classify regulations as being of specific importance tothe user's business. In particular, in some embodiments, the user'sresponses to the questions identify aspects of a company's businessoperations, such as what are the company's primary activities, is thecompany a financial institution, if so which financial products it isactive in, what venues does the company execute trades in, whatexchanges are the trades executed on, which assets is the company on,etc. A company's answers to certain questions may elicit new questionsthat further clarify the company's business operations. The system is anintelligent system, in part, because the questions have beenspecifically curated or designed to consider all aspects of businessoperation that may be relevant to one or more regulatory compliancerequirements. In this way, the system interface elicits information in away that allows the system to intelligently classify the company'sbusiness operations and identify particular regulatory compliance issuesthat are likely to be implicated. This allows the system to assign theregulations relevant to a specific company and automatically generateregulatory compliance information tailored to that company and itsbusiness operations on an ongoing basis.

In another aspect of the system, the system implements a graphical userinterface that displays, in real-time, a dashboard of the most recentregulatory compliance information tailored to that company and itsbusiness operations and allows the company to view tasks identified bythe system that need to be completed in order to comply with one or moreregulations. The dashboard also provides a number of graphical elementsthat provide summaries of the number of regulatory bodies, modules,rules, requirements, and users associated with the company, as well asrecent activity that users have undertaken using the system tools. Insome embodiments, the dashboard further displays recent alert activityand provides access to new documents that have been published related tothe regulations and requirements that the system identifies as beingimplicated by the business's operational data. In this way, userinterface and dashboard provides a central hub where companyrepresentative and team members can log on, view outstanding tasks andthe progress of those tasks in order to manage the workflow environment,as well as receive valuable information about regulatory issues that mayaffect their company and the steps needed to be taken to comply withthose regulations.

In another aspect of the system, the system implements a graphical userinterface that displays task information related to Rules andRequirements that the system determined to be applicable to theparticular user. The task display may display information identifyingthe relevant regulatory entity, the particular rule number that is thebasis for the task being generated, a description of the task, a stageidentifying whether the task is complete or open, a due date forcompleting the task, a notification identifying how active the Rules orRequirements underlying the task are, among others. The task display mayalso the user to assign the task to certain users or consultants to becompleted. Assigned tasks may be displayed on the user's dashboarddisplay when the user logs into the system.

In certain embodiments, the additional information about the regulationand compliance steps is generated by system automatically by scrapingthird-party websites or by using a special form of natural languageprocessing described herein to convert regulatory text into easy-to-readand easy-to-understand summaries that do not necessarily change themeaning of the regulatory text or provide legal advice, but make thetext easier for a user to digest. For example, in some embodiments, thesystem may recognize key terms that are predicted to be difficult forthe reader to comprehend (occasionally referred to as legalese) and mayreplace these words with alternative terms or definitions that assistthe reader in comprehending the regulatory statute. Certain embodimentsmay also replace internal references to external statutory sections witha brief summary of what the external statutory section describes so thatthe user may read and comprehend the regulation without having tonavigate to several regulations and aggregate their content to makesense of the regulatory text. These examples are merely illustrative andare merely illustrative and a person having skill in the art wouldrecognize that variations may be made without departing from the scopeand spirit of the present disclosure.

In several aspects, systems and methods in accordance with the presentdescription create significant efficiencies and cost savings in legal,regulatory, and compliance workflows. These systems and methods enablefirms to identify what laws, regulations, and rules apply to their firmwithout the need to utilize significant resources to achieve regulatoryinformation. In other aspects, the system intelligently monitors andupdates regulatory compliance information in an automated fashion, andallows for the system to maintain an up-to-date taxonomy andclassifications system such that the companies and other users of thesystem can automatically be provided with updated regulatory complianceinformation response to new laws and regulatory requirements, oramendments and changes to existing requirements. In some embodiments,the system may atomically or periodically generates updated complianceand regulatory information. For example, the system may update andmaintain regulatory manuals that can be output to a desired format(whether paper or digital format, such as Portable Document Format (PDF)or Extensible Markup Language (XML) to be distributed to the companiesand its employees in order to inform them of any relevant changes thatmay affect company operations or compliance requirements.

In other aspects, systems and methods in accordance with the presentdescription allow for a novel new way to parse regulations as textstrings, in a manner that reduces qualitative words down tosingle-directional strings (that is, only one outcome is present basedon the words in the string). The systems and methods apply a taxonomyonto each of those strings to support intelligent sorting.

In other aspects, methods in accordance with the present descriptionallow for a provide a regulatory alert index (RAI) that aggregatesinformation related to rules, laws, and regulations, etc., and computesa score or ranking that describes how active each rule, law, orregulation is in the market place. In some embodiments, the RAI iscalculated on a “task” level such that there are two Rules relevant toparticular task, and each one is independently actively, then anaggregate RAI score would appear next to the task that is representativeof the activity in both Rules. In some embodiments, it may be the sum ofthe RAI for each of the two Rules, although it may also be a weighedcomposite score. In this way, the system tracks tasks related to auser's business operations and provides a heat map of the activitysurrounding relevant rules and regulations. The RAI score can take intoaccount data points, such as enforcement actions, speeches, marketcommentary, rule publications, advisory notices (of all kinds), andother official regulator data related to the Rule at issue. In essence,the RAI score alerts the business user of how closely the business usershould monitor this regulation for changes. Beneficially, the systemallows the user to subscribe to alerts or update notifications for eachRule, and the user may utilize the RAI to identify which Rules are mostimportant to that user.

Further features and advantages of the invention, as well as thestructure and operation of various embodiments of the invention, aredescribed in detail below with reference to the accompanying drawings.It is noted that the invention is not limited to the specificembodiments described herein. Such embodiments are presented herein forillustrative purposes only. Additional embodiments will be apparent topersons skilled in the relevant art(s) based on the teachings containedherein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles involvedand to enable a person skilled in the relevant art(s) to make and usethe disclosed technologies.

FIG. 1 is an exemplary system architecture diagram depicting thehigh-level flow and parsing process of qualitative information prior tothe application of a taxonomy to the parsed data.

FIG. 2 is an exemplary diagram of the “taxonomy” data structure, andillustrates the manner in which a taxonomy is created from a series ofqualitative texts.

FIG. 3 is an exemplary diagram of the data feed process and migration ofregulatory information into local servers and databases that enablesreduction of the qualitative text into parsed strings onto which thetaxonomy may be applied.

FIG. 4 is an exemplary diagram of how the system processes the mostgranular level of data to augment and generate summaries to be utilizedin the user processes.

FIG. 5 is an exemplary flow diagram of a parsing process for a set ofqualitative data according to some embodiments.

FIG. 6 is an exemplary flow diagram illustrating how the requirementsare granulized and the taxonomy applied to support the intelligentcreation and automatic updating of a regulatory compliance manual.

FIG. 7 is a representation of an exemplary data structure for storinggranulized data for the processed qualitative data sets.

FIG. 8 is an exemplary display for implementing a graphical userinterface according to certain embodiments that displays a dashboardsummary of activity related to a particular business or user.

FIG. 9 is an exemplary display for implementing a graphical userinterface according to certain embodiments that dynamically displaysrelevant regulatory tasks that were assembled by the system using thetaxonomy.

FIG. 10 is an exemplary display for implementing a graphical userinterface according to certain embodiments that allows a user toresponse to questions generated by the system.

FIG. 11 is an exemplary display for implementing a graphical userinterface according to certain embodiments for generating and updatingcompliance manuals.

FIG. 12 is an exemplary display for implementing a graphical userinterface according to certain embodiments for displaying rules andrelated documents relevant to a business's operational data.

FIG. 13 is an exemplary display for implementing a graphical userinterface according to certain embodiments that allows users to trackheightened issues.

FIG. 14 is an exemplary display for implementing a graphical userinterface according to certain embodiments that allows users to generateadditional tasks related to the business's operational data.

DETAILED DESCRIPTION

Subject matter will now be described more fully hereinafter withreference to the accompanying drawings, which form a part hereof, andwhich show, by way of illustration, specific example embodiments.Subject matter may, however, be embodied in a variety of different formsand, therefore, covered or claimed subject matter is intended to beconstrued as not being limited to any example embodiments set forthherein; example embodiments are provided merely to be illustrative.Likewise, a reasonably broad scope for claimed or covered subject matteris intended. Among other things, for example, subject matter may beembodied as methods, devices, components, or systems. Accordingly,embodiments may, for example, take the form of hardware, software,firmware or any combination thereof (other than software per se). Thefollowing detailed description is, therefore, not intended to be takenin a limiting sense.

Throughout the specification and claims, terms may have nuanced meaningssuggested or implied in context beyond an explicitly stated meaning.Likewise, the phrase “in one embodiment” as used herein does notnecessarily refer to the same embodiment and the phrases “in anotherembodiment” or “in further embodiments” as used herein does notnecessarily refer to a different embodiment. It is intended, forexample, that claimed subject matter include combinations of exampleembodiments in whole or in part.

In general, terminology may be understood at least in part from usage incontext. For example, terms, such as “and”, “or”, or “and/or,” as usedherein may include a variety of meanings that may depend at least inpart upon the context in which such terms are used. Typically, “or” ifused to associate a list, such as A, B or C, is intended to mean A, B,and C, here used in the inclusive sense, as well as A, B or C, here usedin the exclusive sense. In addition, the term “one or more” as usedherein, depending at least in part upon context, may be used to describeany feature, structure, or characteristic in a singular sense or may beused to describe combinations of features, structures, orcharacteristics in a plural sense. Similarly, terms, such as “a,” “an,”or “the,” again, may be understood to convey a singular usage or toconvey a plural usage, depending at least in part upon context. Inaddition, the term “based on” may be understood as not necessarilyintended to convey an exclusive set of factors and may, instead, allowfor existence of additional factors

By way of introduction, systems and methods in accordance with thepresent description provide for, among other applications, an innovativemeans to (a) monitor rules and regulations to identify the most recentregulatory data, classify and assign attributes to that data, andautomatically generate summary and explanatory information for sub-partsof the laws or regulations within that data, (b) create a taxonomysystem that queries users to identify attributes about the user or theuser's company and maps relevant regulations and laws to theirresponses, (c) interpret these attributes and the regulations and lawsin an intelligent and targeted manner in order to assign particularregulatory compliance information, as well as summary and explanatoryinformation that provides assistant to the user or business in complyingwith the regulation or law, to the specific user based on the qualitiesof that user that the system determined to be applicable to thebusiness's operational data, (d) provide a graphical user interface thatallows a user or employee of a business to log into the system andaccess the most recent regulatory compliance information for that useror business in real time, create, assign, and track the completion oftasks that may be required to be completed to comply with theregulations, (e) monitor websites and other sources of regulatorycompliance information in order to identify the most recent regulatoryinformation across all industries, (f) provide portal to that allowsusers to subscribe to alerts that notify the user of new regulations inreal time and assists the users in identifying new regulatoryobligations related to the user's business, (g) dynamically generatecompliance manuals for a company to use in its daily business operationand automatically update those manuals when new regulatory data isidentified, and (h) implement a system that generates a novel andpreviously unknown regulatory alert index that assists users inidentifying how active a particular business requirement for complyingwith a regulation is and how likely it is to be updated.

Other systems, methods, features and advantages will be, or will become,apparent to one with skill in the art upon examination of the followingfigures and detailed description. It is intended that all suchadditional systems, methods, features and advantages be included withinthis description, be within the scope of the invention, and be protectedby the following claims. Nothing in this section should be taken as alimitation on those claims. Further aspects and advantages are discussedbelow.

Referring now to the figures, FIG. 1 depicts an exemplary systemarchitecture diagram depicting the high-level flow and parsing processfor qualitative information prior to the application of a taxonomy tothe parsed data according to some embodiments. Segment 101 represents aset of qualitative content data that is to be broken down and parsed bythe system circuitry and processors. In one example, the qualitativecontent represents a series of regulatory laws for various jurisdictionsand different levels of government within each jurisdiction. In certainembodiments, the qualitative data content about the regulation andcompliance steps is generated by system automatically by scrapingthird-party websites.

Blocks 102, 103, and 104 represent sets of qualitative data at one leveland jurisdiction to be broken down and parsed by the system circuitryand processors. For example, block 102 may be the Code of FederalRegulations, an indexed set of the government's rules. Block 103represents a second set of qualitative data to be broken down and parsedby the system circuitry and processors. For example, block 103 may bethe Federal Register, an indexed publication of government regulationsand other information. Block 104 represents a third set of qualitativedata to be broken down and parsed by the system circuitry andprocessors. Block 104 (and additional blocks not shown) may representinformation retrieved from a number of data sources storing contextualabout each of the laws, rules, or regulations, in addition to thosediscussed in connection with blocks 102 and 103. By way of illustrationbut not limitation, block 104 may include data representing speeches,updates to existing rules, official comments on regulations, or anyother data that can be broken down, parsed, and eventually combined witha taxonomy created by the system.

The elements of segment 105 represent a high-level diagram of theparsing process for each set of qualitative data contained in segment101. In the specific example discussed above, block 105 represents amanner of parsing of the Code of Federal Regulations (block 102),Federal Register (block 103), and other contextual data (block 104 andothers). A similar manner of parsing, however, may be applied in otherfields and to other similar qualitative data sets of relativelyequivalent structure and complexity.

Block 106 represents one or more databases associated with the system,which will accept the data from blocks 102, 103, and 104, and depositthe data into an aggregated and unparsed form. Block 107 represents thefirst level of processing and parsing of the relevant qualitative data.For example, block 107 will represent a system operation that parses thedata to generate a “Category” of data, which may be a vertical categoryof regulatory law or set of laws that are all related to a singleregulatory entity or specialized business area, such as those laws andregulations of the Commodity Futures Trading Commission. Additionally,the system may further process the data at this stage to segregate databy jurisdiction and type, such as federal regulatory obligations, state,county, municipal, and so forth.

Block 108 represents the second level of parsing of the relevantqualitative data. For example, block 108 will represent a systemoperation that parses the data to generate a “Module” of data. A Modulewill contain a set of discrete rules related to the rule, law, orregulation. In some embodiments, a Module may contain only datapromulgated by the same entity or one or more closely related entities,such as one that falls within the umbrella of the vertical category 107.A Module thus will often be a set of qualitative or quantitative rulesfrom individual organizations, such as the National Futures Association,the Chicago Mercantile Exchange, the Intercontinental Exchange, or thatof the Commodity Futures Trading Commission itself (all of which wouldbe overseen by the Commodity Futures Trading Commission described invertical block 107).

Block 108 and its subsequent components may also include “quantitative”data or numerical components retrieved from the qualitative data, forwhich this similar process will also apply.

Block 109 represents the third level of parsing of the relevantqualitative data. For example, it will represent a system operation thatparses the data to generate a “Subject,” which is a subsidiary of eachdistinct Module. In this case, a subject will be a collection of rulesrelated to a particular regulatory topic that is governed by or fallsunder the one or more related organization(s) in the correspondingModule.

Block 110 represents the fourth level of parsing of the relevantqualitative data. For example, it will represent a system operation thatparses the data to generate a set of Rules relating the operationalrequirements of the entities in the particular Subject and Module, whichmay be a subsidiary of each distinct Module. For example, in someembodiments, a Module would be made up of Subjects and Rules related toeach Subject, and the Rules would be the most granular level in whichthe qualitative data is broken down and presented by the originalcreator of the qualitative data (i.e., the source from which thequalitative data was retrieved in block 101). In some embodiments, thisis the last layer of “sorting” of the original qualitative data, and thesystem will not now need to process that the sorted data and generateadditional date that may be used by various processes described herein,although it is envisioned that certain sources of qualitative data maycontain contexts and fields that may require additional sorting steps toreach the most granular level, and a person of skill in the art wouldrecognize that in such a scenario, one or more additional sorting stepsmay be preferred or even required.

Block 111 represents the fifth level of parsing of the relevantqualitative data. For example, it will represent a system operation thatparses the data to generate a “Requirement.” This step is the step inwhich a “rule” has its language parsed, and it is broken down into asingle string. For example, each single string will be made up of abasic pattern of language which cannot be broken down further withoutcausing unintelligible text. In some embodiments, each string may becreated by a system administrator that manually breaks down eachregulatory requirement and law into the smallest discrete steps that mayimplicate a related regulation or a regulatory compliance requirement.In contrast to traditional natural language processing, the system thusassociates these strings as arguments at the most discrete level in away that allows the system to tie each string to information specifiedby the user in response to the questions. For example, some embodimentsmay use a special form of natural language processing described hereinto convert regulatory text into easy-to-read and easy-to-understandsummaries that do not necessarily change the meaning of the regulatorytext or provide legal advice, but make the text easier for a user todigest. The natural language processing may also be used by the systemto determine relationships between certain sets of the qualitative data.For example, the system may determine that one Rule in one Module isrelated to a second rule in another Module. In this way the system canintelligently and automatically learn relationships between discreteModules, Subjects, Rules, and so forth, and utilize these relationshipsin determining additional Requirements that may be relevant toparticular business user. The building of these relationships alsofacilitates other aspects of the system, such as the RAI and heat mapfeatures that identify which Rules and Requirement are most active andneed to be monitored more closely. In some embodiments, the system mayalso generate and maintain a data matrix that links certain sets ofqualitative data to each other (at any level). For example, the systemor an administrator may link a Rule or Requirement to an entire Module,so that the Rule or Requirement is always marked as relevant to theparticular Module. This linking of relationships may occur on any leveland may be customized for a particular business. In this way, thelinking further facilitates the system intelligently and automaticallylearn relationships between discrete sets of data, and allows the systemto customize the relationships for a particular user.

The process described in connection with blocks 107 through 111 of FIG.1 may contain further intermediary components (not depicted). In suchcase, block 111 would still represent the most granular level data, andblock 110 would represent the second-to-last most granular level ofdata, and so forth.

It is important to note that the system also provides an updateprocessor which allows the components associated with block 111 to beupdated or altered at any time either manually, or via API interface,which will automatically populate downstream and update all downstreamprocesses. For example, this means that changes to the qualitative data,or the base level requirements, would be implemented either manually orautomatically in related processes carried out by the system. Thus, thechanges would automatically update the downstream database of updatedrules. In this manner, the system is able to provide an up-to-datetaxonomy of the most recent rules and requirements of the regulatoryrequirements associated with the different data sets 102, 103, 104.

Segment 112 represents the Taxonomy question database. This databasewill be a combination of questions which are structured in the easiestpossible manner with which all questions in a qualitative data set willbe sorted. The maximum number of questions to be utilized will depend onthe size of “Requirements” in the qualitative data set, but should be nolarger than the natural logarithm of the number of requirements.

Blocks 113 represent the individual taxonomical questions that would beutilized in the creation of targeted user outputs. The system (e.g.,Taxonomy engine 114) utilizes the questions in the Taxonomy questiondatabase 112 to intelligently structure a series of questions needed toelicit the user's information and to determine regulatory compliancerequirements. For example, a user's answer to one question in theaffirmative may trigger the system to generate additional questionsrelated to new regulatory issues in order to determine whether theuser's answers implicate an additional regulatory requirement.

Block 114 represents the Taxonomy engine. This engine will aggregate theanswers to the taxonomy questions from block 113 and apply them to theparsed qualitative text in its most granular form, in this example, theRequirements, as described in block 111. The Taxonomy engine willseparate, classify, and sort the user's answers to the taxonomyquestions, so as to only provide the user with qualitative data relevantto it.

Block 115 represents the user's parsed qualitative data after it hasbeen separated, classified, and sorted by the taxonomy. In this example,it would represent only the regulatory rules, laws, or other qualitativedata that is applicable to the user based on the user's answers to thetaxonomy questions. Block 115 represents the final output of the priorprocesses. In some embodiments, block 115 includes a summary ofregulatory compliance data related to a user's business operations. Aswill be discussed further in connection with FIGS. 8-14, the summary mayinclude a list of requirements a business user should be aware of giventhe nature of the user's business operations, or a summary of tasks thatthe business user must address based on regulatory obligations relatedto the business user's business operations. The system may utilize thisinformation to generate information and content to be included inreports or compliance manuals, or displayed on the graphical userinterfaces implemented by the system, such as the user's dashboard,tasks summary page, issues page, reports page, or compliance manualpage.

Block 116 represents the creation of an alert or update notificationthat will be generated that will inform the user that the output fromprocesses described in connection with blocks 101 through 115 isdifferent than it was previously. This allows the system toautomatically inform the user of updates and changes in relevantregulatory compliance information and, if needed, generate new manualsand regulatory compliance information. The user will then be taken backto the final output upon selecting that she understands there was achange.

Referring now to FIG. 2, the process for implementing and using thetaxonomy based classification system according to certain embodiments isillustrated in greater detail. Block 201 represents the collection of aqualitative set of data. For example, a set of regulatory law coded viathe Code of Federal Regulations or Federal Register, as describedsegment 101 of FIG. 1.

Block 202 represents an aggregation and classification of relevantqualitative data and review of the components of the relevant data asdescribed in connection with blocks 106 through 111 of FIG. 1. Theaggregation and classification of relevant qualitative data and reviewof the components of the relevant data may ultimately result in thecreation of a data structure similar to that described in connectionwith FIG. 7.

Block 203 represents the individual taxonomy questions to be developedin order to properly analyze qualitative data from block 201. In oneembodiment, the questions are created by reviewing the content sets andsorting based on the characteristics of each component of thequalitative set. These will be aggregated and structured in a bottom-upapproach until a set of finite questions can be created equal to thenatural logarithm of the total number of discrete “Requirements.” Forexample, a set of Regulations would be reviewed, and a number ofquestions would be developed based on the common attributes of each ofthose regulations. The questions represent each consideration that maynecessary to make a determination about whether the user is incompliance with all regulatory requirements of not only the law inquestion, but any law of regulatory requirement that may be triggered inresponse to a question for that law. In addition, some embodimentsinclude screening questions outside of the direct attributes of theRequirements in order to create more targeted Taxonomies such that theprocess may be streamlined for particular users.

Block 204 represents the Taxonomy Engine, which may be comprised of oneor more servers, distributed databases in operative communication over anetwork, and dedicated circuitry, such as may be implemented using aprogrammable logic array (PLA), application-specific integrated circuit(ASIC), or one or more microprocessors, programmed to execute taxonomylogic that causes the system to perform one or more of the stepsdescribed in connection with FIGS. 1-14, In some embodiments, thetaxonomy logic may be fully embodied as software, firmware, or hardware.The Taxonomy questions and data from blocks 202 and 203 will be enteredinto or communicated to the Taxonomy Engine 204 and combined withrelevant qualitative data set as described in connection with blocks 101through 116 of FIG. 1. Thus, in one aspect, the Taxonomy Engineaggregates parsed qualitative data, generates or receives the individualtaxonomy questions, receives data representing a user's answers to thetaxonomy questions, and analyzes those answers to identify subsets ofdiscrete requirements (as described further in connection with element111 of FIG. 1) that may be related to the particular user or the user'sthe business operation data. In some embodiments, the Taxonomy Enginewill also retrieve and process the data necessary to implement thegraphical user interface features discussed further in connection withFIGS. 8-14.

Referring now to FIG. 3, blocks 301 represents the qualitative data thatwill feed into the qualitative database prior to processing. Forexample, the blocks 301 may represent the Code of Federal Regulations,the Federal Register, and other legal and law-based content, as well asany of the contextual data that is retrieved from one or more datasources.

Block 302 represents the database that will house all of the qualitativedata, both pre-sorted, and post-sorting and after application of anyrelevant changes. Database 302 may comprise a single database or one ormore distributed database in operative communication over a network,such as the Internet.

Referring now to FIG. 4, the process for breaking down a source ofqualitative data to generate rules and requirements using the taxonomybased classification system according to certain embodiments isillustrated in greater detail. At block 401, the system receives thesame rules as generated and described in connection with block 110 ofFIG. 1. In particular, block 401 represents the fourth level of parsingof the relevant qualitative data, and in some embodiments, may representa system operation executed by the Taxonomy engine that parses the datato generate a rule that may be a subsidiary of each distinct Module.

At block 402, the system extracts or retrieves the actual text of therules or data set for block 401 as pulled directly from the qualitativedata set. In one example, block 402 would be the final level of sortingof the qualitative data to generate distinct Modules of subjects andrules on a particular topic. The system will further process the data ineach distinct Module to generate additional data used by the taxonomyengine, but, according to some embodiments, the modularization of thedata in block 402 allows the system to keep the qualitative on distincttopic separate so as to maintain the integrity of the system's processthat generates unique and tailored content for each user or business, asdescribed further herein. However, a person of skill in the art willrecognize that other embodiments may implement alternative datasegregation schemes without departing from the spirit and scope of thepresent disclosure.

At block 403, the system creates or retrieves a summary text of data setfor block 401 that may first be created manually by an administrator toprovide a helpful, user friendly summary of the relevant qualitativedata, but may subsequently processed and created automatically when newupdates to the qualitative data are discovered by the system. In someembodiments, the summary text of data can be used by the system whendisplaying the dashboard when a user is authenticated and logs into thesystem, as well as the content for one or more of the other graphicaluser interfaces described in connection with FIGS. 8-14.

At blocks 404, the system retrieves the same description as generatedand described in connection with block 111 of FIG. 1. In particular,block 404 represents the final level of parsing of the relevantqualitative data. For example, it will represent a system operation thatparses the data to generate a “Requirement.” This step is the step inwhich a “Rule” has its language parsed, and it is broken down into asingle string. For example, each single string will be made up of abasic pattern of language which cannot be broken down further withoutcausing unintelligible text. In some embodiments, each string may becreated by a system administrator that manually breaks down eachregulatory requirement and law into the smallest discrete steps that mayimplicate a related regulation or a regulatory compliance requirement.In contrast to traditional uses natural language processing, the systemthus associates these strings as arguments at the most discrete level ina way that allows the system to tie each string to information specifiedby the user in response to the question. Some embodiments may also usenatural language processing to convert regulatory text into easy-to-readand easy-to-understand summaries that do not necessarily change themeaning of the regulatory text or provide legal advice, but make thetext easier for a user to digest. The natural language processing mayalso be used by the system to determine relationships between certainsets of the qualitative data (e.g., Requirements, Rules, Subjects,Modules, etc.) so that other aspects of the system, such as the RAI andheat map features, may utilize these relationships to identify whichRules and Requirement are most active and need to be monitored moreclosely.

At block 405, the system retrieves the summary text of a singleRequirement, or one of the blocks 404, that may first be createdmanually and subsequently processed and created automatically generatedfor each particular regulatory requirement. For example, it is a summarytext of the most granular rule of a Regulation that will be used by thesystem to generate content to be displayed on the graphical userinterfaces, or used in alerts or notification updates. Portions of thesummary text may come from content generated by the systemadministrator, or through the natural language processing processeddescribed herein. The summary text may also include information that canbe pulled from the database when the system is dynamically generating anoutput, such as a compliance manual, task text, or other application. Inthis way, the system may retrieve the relevant summary text related tothe rules and/or requirements for a particular user's businessoperations and compile them to generate a compliance manual, task text,or other application.

Additionally, the summary text may also include clarification data thatmay be displayed alongside the summary text or in a pop-up as the resultof a user hovering over or clicking on the summary information forparticular Requirement. The clarification data may include anyinformation that the system administrator generated in order to assistthe business user in understanding or assessing the Requirement (e.g.,information explaining definitions found within the Rule or Requirement,information explaining how the Rule or Requirement fits into theregulatory scheme for the particular regulator, information describingrelated Rules and Requirements that the company should also be aware, orother text explaining nuances of the particular Rule or Requirement).Similarly, particular text within a Requirement or summary text may bemarked as definition, and any time the text is used within the system,the text may link to clarification data that includes a definition ofthat term (such as statutory definition, or text from another Rule orSection describing the term).

At block 406, the system generates or retrieves instructional languagetext of a single Requirement, or block 404, that may first be createdmanually and subsequently processed and created automatically. Forexample, in some embodiments the instructional text contains informationdescribing the business requirements and formal requirements forcomplying with regulatory obligations so that the company may determinewhat to do in order to comply with a Requirement. In certainembodiments, the instruction text contains information describing taskinformation related to Rules and Requirements that the system determinedto be applicable to the particular user, similar to the informationdisplayed on the task display described further in connection with FIG.9. Similar to the summary text, the instructional text may includeinformation that can be pulled from the database when the system isdynamically generating an output, such as a compliance manual, tasktext, or other application. Portions of the instructional text may comefrom content generated by the system administrator, or through thenatural language processing processed described herein. Instructionaltext may also come from one or more secondary sources associated withthe Requirement when it was retrieved, such as speeches, updates toexisting rules, official comments on regulations, or other contentrelated to the Requirement or to the corresponding Rule, Subject, orModule.

At block 407, the system generates or retrieves compliance manual textof a single Requirement, or block 404, that may first be createdmanually and subsequently processed and created automatically. Similarto the summary text and instructional language, it will be the text thatis automatically pulled from the database when the system is dynamicallygenerating an output, such as a compliance manual, task text, or otherapplication. In some embodiments, the compliance manual text willcomprise text pulled directly from the Rules or from documents,speeches, or other texts that were published by the regulatory agenciesthat publish the rules. In other embodiments, the compliance manual textmay be a restatement of the Rule in general terms without specificreferences to other regulatory texts. Portions of the compliance manualtext may come from content generated by the system administrator,through the natural language processing processed described herein, orfrom the original qualitative data that was retrieved and sorted by thesystem. The compliance manual text may be particularly helpful to becompiled inserted into a holistic compliance manual based on all of theRequirements that apply to a particular user's business. In someembodiments, these manuals may be automatically generated when a userfirst uses the system, as well as alerts or new manuals generated whenthe rules change.

It is important to note that the data and information determined inconnection with blocks 404 through 407 can be updated or altered at anytime either manually, or via API interface, which will automaticallyupdate all downstream processes. Here, it means changes to thequalitative data, or the base level Requirements (block 404), along withany updates or alterations to any of the dependent text of block 405through 407. This could be implemented either manually or automatically.Here, it means the updates or alterations to the Regulatory Requirementthemselves, and any text that was interpretive of this data anddependent on such data. Thus, these updates to blocks 404 through 407would automatically update the downstream database of updated rules. Insome embodiments, a user may utilize the graphical user interface tosubscribe to update notifications. In this instance, the updatenotification may be displayed on a graphical user interface (such as theuser's dashboard when the user logs into the system) or may beincorporated into the user's compliance manual and automatically sent tothe user when the system identifies that material related to that user'sbusiness has updated. In these scenarios, the system allows the user tomaintain up-to-date recognizes and dynamically compile the most recentand relevant information.

Block 408 represents the database that receives the data from blocks 402and 403. Database 402 and 403 may each comprise a single database or oneor more distributed database in operative communication over a network,such as the Internet

Referring now to FIG. 5, FIG. 5 represents a more detailed diagram ofthe hierarchy generated according a flow process similar to thatdescribed in connection with segment 105 of FIG. 1, except that itincludes multiple ultimate Requirements (as described in connection withblocks 101 to 111 of FIG. 1). Here, at block 501 the qualitative data issplit up into multiple Requirements 502 before processing. Requirements502 represent the most granulized level. The vertical information foreach requirement 502 is generated by the processing steps that precedethe requirement in blocks 510 (category), 511 (module), 512 (subject),and 513 (rule), similar to as described in blocks 101 to 110 of FIG. 1.Although depicted as a single vertical stream, one of skill in the artwould recognize that each rule may have a vertical stream with a numberof branches at each level as may be appropriate.

Blocks 502 thus represent a similar description as described inconnection blocks 101 through 111 of FIG. 1, but shows that there mayultimately be multiple Requirements for each rule or qualitative dataset 501. One of skill in the art would recognize that there are aninfinite number of Requirements and the number is only restricted by thesize of the original qualitative text that is being granulized into itsbase form.

Block 504 represents the entry of the granulized data into the database.The entry of the granulized data may take a form similar to thatdescribed in connection with FIG. 7.

Referring now to FIG. 6, an exemplary flow diagram according to certainembodiments is shown illustrating how the requirements are granulizedand the taxonomy applied to support the intelligent creation andautomatic updating of a regulatory compliance manual. Blocks 601represents a similar description as described in connection with blocks101 to 113 of FIG. 1, although here three distinct qualitative data setsare depicted. In this example, the three distinct qualitative data setshave been chosen by the system because they have been determined to berelevant to the user's business operation data. In this regard, block602 represents the user's selection of the answers to the Taxonomyquestions and the system utilizes these answers to help identify theuser's business operation data. Block 603 represents a similardescription as described in connection with blocks 404 through 407 ofFIG. 4, where the system receives the Requirements for the user'sbusiness, generates summary text related to the Requirements, generatesinstruction language related to the Requirements, and generates manualtext to be used in dynamically generated output. At block 603, thesystem may also identify any alteration or changes made to the baselevel requirements or the Requirement itself (including, but not limitedto the data changed or new data identified as it related to the summarytext, instructional language, and manual text as described in connectionwith blocks 405 through 407 of FIG. 4). For example, in addition tostoring the text or summary of text of the Rule or Requirement, thesystem may also generate and store altered text as may be needed tosupport any number of other applications. In some embodiments, thesystem may store altered text that converts each Rule or Requirementinto compliance verbiage, task management verbiage, or training verbiageamong other applications. The system may then dynamically draw from eachof these verbiage texts when constructing a product (such as a manual,task list, etc.) to display or provide to the user. Each verbiage textwill thus reflect the corresponding rule and regulatory requirement.

Block 604 represents the database of all Compliance Manual Requirements,as described in connection with block 407 of FIG. 4, based on thequalitative text entered. In the previously discussed example, it refersto Federal Regulations and text of federal regulatory law. It may alsorefer to the database of any Requirements (as described in connectionwith blocks 101 through 111 of FIG. 1), or any alterations or changesmade to the base level Requirements (as described in connection withblocks 101 through 111 of FIG. 1) to create a new altered data set.

Block 605 represents the application of the answers to the Taxonomy (asdescribed in block 602) to the database of requirements (as described inblock 604), that the system will then classify and sort into therelevant obligations. For example, the system will sort the data inblock 604 and eliminate inapplicable Regulations.

Block 606 represents the database into which the sorted qualitative datawould be deposited. In this case, it is the sorted Compliance ManualText (as described in connection with block 407 of FIG. 4) that is basedon interpretation of the base level text in the base Requirements (asdescribed in connection with blocks 101 through 111 of FIG. 1).

Block 607 represents the user output that the user would view of thesorted qualitative data, in this case, the compliance manualobligations. In some embodiments, the compliance manual obligations maybe displayed on the graphical user interface discussed further inconnection with FIGS. 8-14, and the system may allow the user todownload the compliance manual obligations to use as a holisticcompliance manual. In other scenarios, it may represent the task text,such as the text used to generate the tasks displayed on graphical userinterface depicted in FIG. 9, or any other text used to generate otherproducts in accordance with the present description.

Block 608 represents a combination of the qualitative data from block607. Thus, block 608 represents the combination of all of the sorteddata, the compliance manual obligations, and compiling of all of thatdata into a single qualitative text. In this example, that represents aCompliance Manual, but may be any number of products in other contexts.

It is important to note that the distinct qualitative data setsdescribed in connection with block 601 can be updated or altered at anytime either manually, or via API interface, which will automaticallyupdate all downstream processes. In response to the updating of data inblock 601, the system would populate any changes to the Taxonomyquestions those changes would flow to the user.

Similarly, it is important to note that the Requirements for the user'sbusiness, summary text related to the Requirements, instruction languagerelated to the Requirements, and manual text described in connectionwith block 603 can be likewise updated or altered at any time eithermanually, or via API interface, which will automatically update alldownstream processes. In response to the updating of data in block 603,the system would populate any changes to the qualitative data, or theCompliance Manual Requirements, into the product created at block 608such that the user is displayed the most recent information.

Referring now to FIG. 7, a representation of an exemplary data structurefor storing granulized data for the processed qualitative data isdepicted. As described in connection with blocks 502 and 504 of FIG. 5,each granulized part of each rule is stored in a database. As depictedin FIG. 7, the database entry for each granulized part of each rule isassociates that part with the rule identification information 701, ruletext 702, and the specific requirement part 703 created by the system,such as described in connection with block 502 of FIG. 5. For eachrequirement part 703, a summary is provided that explains the relevantrequirement part 703 at a high or user-friendly level. Similarly, thesystem may associate a number of textual strings or summaries that thesystem may pull from when dynamically creating relevant products. Forexample, for each requirement part 703 of each rule 701, the system maystore compliance manual text 705 and task text 706, as well as anynumber of textual representations 707 for other application. Each ofthese texts are designed to facilitate the dynamic creation of therelevant product by providing, for example, the description of thecompliance requirements or tasks that must be undertaken by the user tosatisfy regulatory requirements.

Referring now to FIG. 8, an exemplary display for implementing agraphical user interface according to certain embodiments that displaysa dashboard summary of activity related to a particular business oruser. The dashboard display of the embodiment depicted in FIG. 8displays the company's name 803 alongside a summary of the number ofregulatory bodies 804 implicated by the business's operational data, thenumber of distinct modules of regulations 811 implicated by thebusiness's operational data, the number of distinct rules 811 implicatedby the business's operational data, the number of requirements 813 thatthe system identified as implicated by the business's operational data,and the number of users 814 that are associated with the company'saccount. The dashboard display may also contain other visual elementsthat provide a graphical representation of the outstanding tasks 805 andwhat percentage have been reviewed or addressed within the last week,month, and/or year. In some embodiments, the dashboard will also displaya summary of recent activities 806 that the company has completed usingthe system, a summary of recent alerts 807 that may include alerts onnew activities needing to completed, updates or changes to Rules orRequirements that are relevant to the business's operational data,and/or document updates showing, for example, new documents, speeches,or other texts that were published by the regulatory agencies and thatare related to Rules or Requirements that the system identified as beingimplicated by the business's operational data. Clicking on any thesevisual elements will take the user to the content, such as theregulation itself, the document itself, or the task itself that the teamis working on. In some embodiments, the information displayed on thedashboard is updated in real-time as the system identifies additionalinformation related to the business's operational data. Additionally, auser can change their account and/or corporate entity by clicking on thebuttons 801 and 802. In some embodiments, clicking on buttons 801 and802 will change the display to the relevant display for that particularuser. For example, a consultant working with multiple parties may switchbetween companies using button 802, or if the user is part of a holdingcompany, the user may switch between a different corporate entity withinthat holding company. The dashboard display also displays a list ofadditional links 815 that allows the user to navigate to additionaldisplays within the system, such as those described further inconnection with FIGS. 9-14. Although not depicted, the dashboard displaymay also display a summary of task information for tasks that areassigned to the particular account identified by 801, such as thosetasks assigned to the user, as described further in connection with FIG.9

In some embodiments, the dashboard displays the most recent regulatorycompliance information tailored to a particular company and thatcompany's operations. The dashboard display allows the company to viewtasks identified by the system that need to be completed in order tocomply with one or more regulations. In this way, user interface anddashboard provides a central hub where company representative and teammembers can log on, view outstanding tasks and the progress of thosetasks, and navigate to other displays in order to manage the workflowenvironment, as well as receive valuable information about regulatoryissues that may affect their company and the steps needed to be taken tocomply with those regulations. Referring now to FIG. 9, an exemplarydisplay for implementing a graphical user interface according to certainembodiments that dynamically displays relevant regulatory taskinformation assembled by the system using the taxonomy is depicted. Asshown in FIG. 9, the system may display the regulatory information 901for each task that identifies the regulating entity (which may be wherethis subset of the qualitative data 101 was scraped from by the system),the rule number 902, a task description 903, stage 904 describingwhether the task is open, closed, or partially complete, notes 905 onthe task that have been entered by one or more users associated with theaccount or corporation, due date 906 for competing the task (which maybe assigned by the a user for the corporation or determined by thesystem based on the information identified in the user's responses tothe taxonomy questions), and assignment filed 907 that allows the system(or a user for the corporation) to assign the task to be completed byanother user (or to a third party contract or service provider), amongother fields. In some embodiments, the data for each of these fields maybe dynamically pulled from the system databases (such as the datastructure described in connection with FIG. 7) as needed by the systemto construct the relevant task list for the particular user. In relatedembodiments, a tasking algorithm may be used to help generate andorganize tasks, such as by considering the hierarchy of Rules, Subjects,Modules, and Category to determine similar tasks and group themtogether. Additionally, the tasking algorithm may also utilize naturallanguage processing or elastic search to create a keyword score in aneffort to clump tasks together based on the number of shared or similarwords between the tasks. The algorithm may also group tasks togetherbased on frequency, such as whether they all occur daily, weekly,monthly, or annually. In this way, the system may list tasks on the taskpage in a specific order in order to assist the user in providing astreamlined approach to reviewing compliance and review, and eliminateduplication of tasking.

As will be apparent to one of ordinary skill in the art, the depictedinterface is exemplary and non-limiting and modifications may be madewithout departing from the spirit and scope of the present disclosure.

In certain embodiments, the task display is the display that providesthe information at the core of the system. Other processes describedherein facilitate the system taking all of the Rules and Requirementsand sorting them based on how a user answers the taxonomy questions togenerate the tasks that are displayed on the task display. The taskdisplay provides a page for a company to manage many of its dailyobligations. The task display also includes a display notification forthe RAI 908 of each task that allows the user to monitor how active theregulations related to the task are and links to other services 909. Inone embodiment, the magnifying glass button 910 will display detailspage having the more intricate details of each task, includingadditional important regulatory text and task background. The trianglebutton 911 can be used to flags the task an important “issue” that needsto be resolved. The trash icon 912 deletes the Requirement correspondingto the task and may remove it from recurring in the future.Beneficially, the system can intelligently learn from the user's actionsassociated with each task, such that if certain tasks related toRequirements in a particular Subject, Module, Category, etc., areconsistently flagged or deleted by the user for a particularcorporation, then the system may determine that those Requirements areor are not applicable to the company. Tasks which are consistentlyidentified as “issues,” for example, may be displayed directly on thedashboard display described in connection with FIG. 8, and any updatenotifications for such task may be displayed with higher priority.Additionally, a user can change their account and/or corporate entity byclicking on the buttons 913 and 914. Clicking on buttons 913 and 914will change the display to the relevant display for that particularuser. For example, a consultant working with multiple parties may switchbetween companies using button 914, or if the user is part of a holdingcompany, the user may switch between a different corporate entity withinthat holding company.

The task window also provides the user with information related to theRAI 908 for a particular task. As described herein, the RAI aggregatesinformation related to rules, laws, and regulations, etc., and computesa score or ranking that describes how active each rule, law, orregulation is in the market place. In this way, the system tracks tasksrelated to a user's business operations and provides a heat map of theactivity surrounding relevant rules and regulations. The RAI score cantake into account data points, such as enforcement actions, speeches,market commentary, rule publications, advisory notices (of all kinds),and other official regulator data related to the Rule at issue. Inessence, the RAI score alerts the business user of how closely thebusiness user should monitor this regulation for changes.

In some embodiments, the RAI is calculated on a “task” level such thatthere are two Rules relevant to particular task, and each one isindependently actively, then an aggregate RAI score would appear next tothe task that is representative of the activity in both Rules. In someembodiments, it may be the sum of the RAI for each of the two Rules,although it may also be a weighed composite score. For example, in apreferred embodiment, the system has a set of default multipliers foreach Category (or alternatively, each Module or Subject). Thesemultipliers are determined by the system administrator based on therelative importance to a typical business's daily operations. The systemmay determine the number of documents and item stored in the set ofqualitative data that cite to the particular Rule, and apply theCategory Multiplier to the total number of documents. As onenon-limiting example, the Category for a task may be EnforcementActions, and the Enforcement Actions may receive a multiplier of 2. TheRule at issue for the user's business may be Rule 2-50, and the systemmay examine the stored qualitative data and determine that there arefive documents reference Rule 2-50. Given the Category Multiplier of 2,then the RAI for Rule 2-50 would be 10. In some embodiments, the systemmay also implement a time decay procedure for the RAI, such that thesystem accounts for whether the volatility of a Rule was a one-timeoccurrence, or whether the Rule changes often and on ongoing basis. Inother embodiments, the system may standardize the RAI to another value,such as a rating out of 100. These examples are non-limiting and aperson of ordinary skill in the art would recognize that variations maymake without departing from the scope and spirit of the presentdisclosure. Beneficially, the system also allows the user to subscribeto alerts or update notifications for each Rule, and the user mayutilize the RAI displayed on the task window to identify which Rules aremost important to that user.

Referring now to FIG. 10, an exemplary display for implementing agraphical user interface according to certain embodiments that allows auser to response to questions generated by the system is depicted(referred to here as the Navigator page). As shown in FIG. 10, in someembodiments the questions 1001, 1002, 1003, and 1004 may be displayed insequential fashion with the system dynamically determining thesubsequent question to display in response to the user's initialselections, such as selections 1005 and 1006. Thus, in this example,questions 1003 or 1004 will be displayed once the user selects theanswer to questions 1001 or 1002. In this way, the user enters responsesto the questions that are intelligently curated based on a prior seriesof attributes that the system determined about the user using answers1001 and 1002. Thus, the user's answers to the curated questions elicituser-specific information and the systems back-end architecture,consisting of one or more distributed network servers, processors,and/or databases, utilizes the user's answers and the aforementionedtext strings (such as Rules 110 or Requirements 111) that are sorted andclassified by the taxonomy in order to intelligently classifyregulations as being of specific importance to the user's business. Theuser's responses to the questions identify aspects of a company'sbusiness operations, such as what are the company's primary activities,is the company a financial institution, if so which financial productsit is active in, what venues does the company execute trades in, whatexchanges are the trades executed on, which assets is the company on,etc. A company's answers to certain questions may elicit new questionsthat further clarify the company's business operations if the systemneeds additional information in order to classify one of the Rules orRequirements as applying to that particular user. In this way, thesystem interface elicits information in a way that allows the system tointelligently classify the company's business operations and identifyparticular regulatory compliance issues that are likely to beimplicated. The system will then assign the Rules and Requirements tothe company's account when the system determines that the companyoperates in a way that is likely to implicate the Rule or Requirement.The system can use this information to automatically generate regulatorycompliance information tailored to that company and its businessoperations on an ongoing basis, as described further in connection withFIGS. 8, 9, and 11-14. If a company needs to update information as thestandard business operations change, then the company can utilize theNavigator menu depicted in FIG. 10 to edit, add, or delete selectionslater. In the embodiment depicted in FIG. 10, the particular display isthe main “categorization” page for a company. Additional pages will beparticularly tailored for each “sector” of the economy so that thesystem can intelligently identify more specific aspects of the company'soperational data. For example, sectors such as derivatives, securities,aviation, and so forth, will have additional Navigator pages that builtdown from jurisdiction (i.e., federal, state, county, municipal, etc.)and account for any nuances within that jurisdiction and sector.

In certain embodiments, this data is used by the Taxonomy engine tostreamline user workflows described in connection with FIGS. 8, 9, and11-14. In other words, the user can click on the different options,which will create different custom workflows that tailored to thatspecific user. As will be apparent to one of ordinary skill in the art,the depicted interface is exemplary and non-limiting and modificationsmay be made without departing from the spirit and scope of the presentdisclosure.

Referring now to FIG. 11, an exemplary display is shown for implementinga graphical user interface according to certain embodiments forgenerating and updating compliance manuals. The display illustrated inFIG. 11 allows company to automatically build and maintain a compliancemanual for their business, such as further described in connection withFIGS. 4 and 6. In some embodiments, the compliance manual generatedusing this display is based on the Rules and Requirements that thesystem has determined to related to the business's operational data. Thesystem may further use the display to generate additional contentdirectly to the company's operations that it completes each day. Forexample, the user may utilize the text entry field 1101 to pull up thecurrent text in a section of the compliance manual and generateadditional text and add it to one or more sections of the compliancemanual using the update button 1102. The display also displays a seriesof links as a table of contents tree 1103 that the user may click tobring the user to that section on the page of the compliance manual. Thedisplay also allows the user to download the compliance manual as PDFusing button 1104, and although not shown, may also allow the useroutput the compliance manual to a desired format (whether by printing topaper or another digital format, such as an Extensible Markup Language(XML) format) to be distributed to the companies and its employees inorder to inform them of any relevant changes that may affect companyoperations or compliance requirements. Beneficially, in someembodiments, the system may atomically or periodically generates updatedcompliance and regulatory information. For example, the data andinformation that is compiled to create the compliance manual ismaintained by the system, and the system may utilize one or morecrawlers that recognize when that data is updated or altered at any timeeither manually, or via API interface. When an update is recognized bythe system the system will automatically update all downstream processesthat utilize that data. Thus, the Requirements or manual text, summarytext, instructional text, etc. that forms part of the compliance manualmay automatically be updated and altered in response to new changes toregulations.

Additionally, the compliance manual generated using the display of theembodiment depicted in FIG. 11 may also include portions of the summarytext of data described in connection with block 405, the instructionallanguage text described in connection with block 406, and/or compliancemanual text described in connection with block 407 of FIG. 4. Asdescribed in connection with FIG. 4, the system generates summary textto help convert regulatory text into easy-to-read and easy-to-understandsummaries that do not necessarily change the meaning of the regulatorytext or provide legal advice, but make the text easier for a user todigest. The system also generates instructional text on what to do inorder to comply with a Requirement, which may come from speeches,updates to existing rules, official comments on regulations, etc. Thesystem also generates compliance manual text based on all of theRequirements that apply to a particular user. Compliance manualsgenerated using the display of FIG. 11 can include data form each ofthese sources that is aggregated and compiled to form the contentaccessible using the table of contents tree 1103, and which isultimately incorporated into the compliance manual when it is exported,such as by using button 1104 to download the manual as a PDF.

Referring now to FIG. 12, an exemplary display is shown for implementinga graphical user interface according to certain embodiments fordisplaying rules and related documents relevant to a business'soperational data. The display illustrated in FIG. 12 allows company viewand access all the Rules, Requirements, and/or any correspondingancillary documents related to the Requirements (i.e. EnforcementActions, Speeches, Clarification Notices) in a single place within thesystem. In the example illustrated in FIG. 12, link 1201 allows the userto access all documentation that has been scraped and indexed by thesystem. Link 1202 allows the user to access all documentation that thesystem has determined may apply to the user based on the business'soperational data and how the user answered the taxonomy questionsdescribed in connection with FIG. 10.

Referring now to FIG. 13, an exemplary display is shown for implementinga graphical user interface according to certain embodiments that allowsusers to track heightened issues. The display illustrated in FIG. 13allows users to track heightened issues, like complaints ornon-compliance issues issued by a user of the account. In someembodiments, the users can also directly email into the system to createa heightened alert that is then displayed on the display for theappropriate company and users. In the embodiment depicted in FIG. 13,three heightened issues are displayed with fields specifying the number1305 identifying the heightened issue, the issue date 1306 for theheightened issue, the type 1307 of the heightened issue, the assigneduser 1308 for the heightened issue, the priority 1309 for the heightenedissue (such as whether it's a high, medium, or low priority), and adescription 1310 of the heightened issue. Additionally, a report issuebutton 1304 is provided that navigates to a page where the user canenter information to report additional heightened issues. In certainembodiments, when the user clicks on the issue numbers 1302, 1303, thesystem will display an additional screen with details for thatparticular issue number.

Referring now to FIG. 14, an exemplary display is shown for implementinga graphical user interface according to certain embodiments that allowsusers to generate additional tasks related to the business's operationaldata. The display illustrated in FIG. 14 allows users to create and addadditional tasks to the task page that are specific to that company. Themod build page allows the user to utilize the system to create completeworkflows that account for idiosyncratic obligations associated with thecompany's daily business operations. Similar to the task displaydescribed in connection with FIG. 9, they system may display theregulatory information 1401 for each task that identifies the regulatingentity (which may be where this subset of the qualitative data 101 wasscraped from by the system), the RAI value 1402, the rule number 1403, atask description 1404, stage 1405 describing whether the task is open,closed, or partially complete, notes 1406 on the task that have beenentered by one or more users associated with the account or corporation,due date 1407 for competing the task (which may be assigned by the auser for the corporation or determined by the system based on theinformation identified in the user's responses to the taxonomyquestions), and assignment filed 1408 that allows the system (or a userfor the corporation) to assign the task to be completed by another user(or to a third party contract or service provider), and other fields. Insome embodiments, the data for each of these fields may be dynamicallypulled from the system databases (such as the data structure describedin connection with FIG. 7) as needed by the system to construct therelevant task list for the particular user.

Although not shown, related embodiments may also provide a graphicalinterface that allows users to comment on potential actions or currentevents, such as regulations that are being considered by regulatoryagencies. The system may parse proposed rules for agencies in a similarmanner as the active rules, but instead of introducing those rule intothe qualitative data set used for generating Requirements, the systemmay maintain those proposed rules in a separate module that allows usersto review the rules and comment on the potential actions. User commentscan be aggregated by the system and automatically submitted to theregulatory agency, such as via API into the agency's website.

Note that various applications in accordance with the presentdescription may include the apparatus and systems of various embodimentscan broadly include a variety of electronic and computer systems. Inparticular, each and every operation described herein may implemented bycorresponding hardware and circuitry. For example, each and everyoperation may have its own dedicated circuitry, such as may beimplemented using a programmable logic array (PLA), application-specificintegrated circuit (ASIC), or one or more programmed microprocessors. Insome embodiments, each of the operation may be performed by system logicthat may include a software controlled microprocessor, discrete logic,such as an ASIC, a programmable/programmed logic device, memory devicecontaining instructions, a combinational logic embodied in hardware, orany combination thereof. Accordingly, logic may be fully embodied assoftware, firmware, or hardware. Other embodiments may utilize computerprograms, instructions, or software code stored on a non-transitorycomputer-readable storage medium that runs on one or more processors orsystem circuitry of one or more distributed servers and databases. Thus,each of the various features of the operations described in connectionwith the embodiments of FIGS. 1A-14 may be implemented by one or moreprocessors or circuit components of one or more distributed computers,servers, or databases, that, in conjunction, are configured to executeinstructions to perform the function by executing an algorithm inaccordance with any steps, flow diagrams, drawings, illustrations, andcorresponding description thereof, described herein.

The aforementioned servers and databases may be implemented through acomputing device. A computing device may be capable of sending orreceiving signals, such as over a wired or wireless network, or may becapable of processing or storing signals, such as in memory as physicalmemory states, and may, therefore, operate as a server. Thus, devicescapable of operating as a server may include, as examples, dedicatedrack-mounted servers, desktop computers, laptop computers, set topboxes, integrated devices combining various features, such as two ormore features of the foregoing devices, or the likeServers may varywidely in configuration or capabilities, but generally, a server mayinclude a central processing unit and memory. A server may also includea mass storage device, a power supply, wired and wireless networkinterfaces, input/output interfaces, and/or an operating system, such asWindows Server, Mac OS X, UNIX, Linux, FreeBSD, or the like. Devices foraccessing the system interfaces may include, for example, a desktopcomputer or a portable device, such as a cellular telephone, a smartphone, a display pager, a radio frequency (RF) device, an infrared (IR)device, a Personal Digital Assistant (PDA), a handheld computer, atablet computer, a laptop computer, a set top box, a wearable computer,an integrated device combining various features, such as features of theforegoing devices, or the like.

While the computer-readable medium as described or set forth in theappended claim may be described as a single medium, the term“computer-readable medium” may include a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” may also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein. The “computer-readablemedium” may be non-transitory, and may be tangible.

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent to those of skill in the art upon reviewingthe disclosure. Other embodiments may be utilized and derived from thedisclosure, such that structural and logical substitutions and changesmay be made without departing from the scope of the disclosure.Additionally, the illustrations are merely representational and may notbe drawn to scale. Certain proportions within the illustrations may beexaggerated, while other proportions may be minimized. Accordingly, thedisclosure and the figures are to be regarded as illustrative ratherthan restrictive.

One or more embodiments of the disclosure may be referred to herein,individually and/or collectively, by the term “invention” merely forconvenience and without intending to voluntarily limit the scope of thisapplication to any particular invention or inventive concept. Moreover,although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b) and is submitted with the understanding that it will not beused to interpret or limit the scope or meaning of the claims. Inaddition, in the foregoing Detailed Description, various features may begrouped together or described in a single embodiment for the purpose ofstreamlining the disclosure. This disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter may be directed toless than all of the features of any of the disclosed embodiments. Thus,the following claims are incorporated into the Detailed Description,with each claim standing on its own as defining separately claimedsubject matter.

The above disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover all suchmodifications, enhancements, and other embodiments, which fall withinthe true spirit and scope of the present invention. Thus, to the maximumextent allowed by law, the scope of the present invention is to bedetermined by the broadest permissible interpretation of the followingclaims and their equivalents, and shall not be restricted or limited bythe foregoing detailed description. While various embodiments of theinvention have been described, it will be apparent to those of ordinaryskill in the art that many more embodiments and implementations arepossible within the scope of the invention. Accordingly, the inventionis not to be restricted except in light of the attached claims and theirequivalents.

I claim:
 1. A system for generating a regulatory alert index usingmodularized data and taxonomy-based classifications of regulatoryobligations, the system comprising: a plurality of databases storingregulatory compliance data; a plurality of processors that process theregulatory compliance data to generate business requirements forcomplying with regulatory obligations; wherein the plurality ofprocessors are further configured to identify new regulatory compliancedata published by regulating entities and update the correspondingstored regulatory compliance data when new information is identified;and a taxonomy engine that determines a regulatory alert index score foreach of the generated business requirements based on how often theplurality of processors identify new regulatory compliance data relatedto the generated business requirement.
 2. The system of claim 1, whereinthe regulatory compliance data comprises rules published by regulatorybodies, and the regulatory alert index score is based on how often theregulatory bodies update the corresponding rules.
 3. The system of claim1, wherein the regulatory compliance data comprises market dataincluding a plurality of enforcement actions, speeches, marketcommentary, rule publications, and advisory notices related to rulespublished by regulatory bodies, and the regulatory alert index score isbased on how often new market data is identified.
 4. The system of claim1, wherein the regulatory alert index score for each of the generatedbusiness requirements is displayed on a graphical user interfacealongside a task related to the corresponding business requirement. 5.The system of claim 4, wherein the task comprises an action that thefirst business user must complete to comply with regulatory obligationsrelated to the corresponding business requirement.
 6. The system ofclaim 4, wherein the task is related to two or more correspondingbusiness requirements, and the regulatory alert index score displayedalongside the task is a weighted sum of the regulatory alert indexscores for the two or more corresponding business requirements.
 7. Thesystem of claim 1, wherein the plurality of processors are furtherconfigured to parse the regulatory compliance data to generate ahierarchy of categories, modules, subjects, and distinct rules withinthe regulatory compliance data.
 8. The system of claim 7, wherein eachof the categories in the hierarchy have a default multiplier, and theregulatory alert index score for any business requirements generatedfrom a rule falling under the category is multiplied by thecorresponding default multiplier.
 9. The system of claim 1, wherein theregulatory alert index score is computed on a standardized scale. 10.The system of claim 1, wherein the taxonomy engine is further configuredto receiving operational data for a business and identify a subset ofthe generated business requirements related the business's operationaldata.
 11. The system of claim 10, wherein plurality of processors arefurther configured to notify the business when the stored regulatorycompliance data corresponding to subset of generated businessrequirements is updated, and wherein the notification to the businessincludes the regulatory alert index scores.
 12. A computer-implementedmethod for generating a regulatory alert index, comprising: storingregulatory compliance data for a plurality of businesses in a pluralityof databases; generating, by one or more processors, businessrequirements related to regulatory rules from the stored regulatorycompliance data; identifying, by the one or more processors, newregulatory compliance data published by regulating entities; updating,by the one or more processors, the corresponding stored regulatorycompliance data when the new regulatory compliance data is identified;generating a regulatory alert index score for each of the generatedbusiness requirements based on how often the new regulatory compliancedata related to the generated business requirement is identified. 13.The method of claim 12, wherein the regulatory compliance data comprisesrules published by regulatory bodies, and the regulatory alert indexscore is based on how often the regulatory bodies update thecorresponding rules.
 14. The method of claim 12, wherein the regulatorycompliance data comprises market data including a plurality ofenforcement actions, speeches, market commentary, rule publications, andadvisory notices related to rules published by regulatory bodies, andthe regulatory alert index score is based on how often new market datais identified.
 15. The method of claim 12, further comprising: parsingthe regulatory compliance data to generate a hierarchy of categories,modules, subjects, and distinct rules within the regulatory compliancedata.
 16. The method of claim 15, wherein each of the categories in thehierarchy have a default multiplier, and the regulatory alert indexscore for any business requirements generated from a rule falling underthe category is multiplied by the corresponding default multiplier. 17.The method of claim 12, further comprising: receiving, by the one ormore processors, operational data for a business, and identifying, bythe one or more processors, a subset of the generated businessrequirements related the business's operational data.
 18. The method ofclaim 17, further comprising notifying, by the one or more processors,the business when the stored regulatory compliance data corresponding tosubset of generated business requirements is updated, and wherein thenotification to the business includes the regulatory alert index scores.19. The method of claim 12, wherein the regulatory alert index score foreach of the generated business requirements is displayed on a graphicaluser interface alongside a task related to the corresponding businessrequirement.
 20. A system for generating a regulatory alert index usingmodularized data and taxonomy-based classifications of regulatoryobligations, the system comprising: a means for storing regulatorycompliance data for a plurality of businesses; a means for generatingbusiness requirements related to regulatory rules from the storedregulatory compliance data; a means for identifying new regulatorycompliance data published by regulating entities; a means for updatingthe corresponding stored regulatory compliance data when the newregulatory compliance data is identified; a means for generating aregulatory alert index score for each of the generated businessrequirements based on how often the new regulatory compliance datarelated to the generated business requirement is identified.